home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000249_nsb@thumper.bellcore.com _Fri Oct 23 10:52:42 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <nsb@thumper.bellcore.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA10984; Fri, 23 Oct 92 10:52:42 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA09586; Thu, 22 Oct 92 20:24:09 +0100
  6. Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
  7.     id <AA14510> for www-talk@nxoc01.cern.ch; Thu, 22 Oct 92 15:23:11 EDT
  8. Received: by greenbush.bellcore.com (4.1/4.7)
  9.     id <AA18177> for ned@innosoft.com; Thu, 22 Oct 92 15:23:10 EDT
  10. Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
  11.           via MS.5.6.greenbush.galaxy.sun4_41;
  12.           Thu, 22 Oct 1992 15:23:05 -0400 (EDT)
  13. Message-Id: <0etjyNa0M2Yt56y3N_@thumper.bellcore.com>
  14. Date: Thu, 22 Oct 1992 15:23:05 -0400 (EDT)
  15. From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset=US-ASCII
  18. To: Larry Masinter <masinter@parc.xerox.com>
  19. Subject: Re: misconceptions about MIME [long]
  20. Cc: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
  21.         www-talk@nxoc01.cern.ch, connolly@pixel.convex.com,
  22.         Ned Freed <ned@innosoft.com>
  23. In-Reply-To: <92Oct22.113048pdt.101795@poplar.parc.xerox.com>
  24. References: <92Oct22.113048pdt.101795@poplar.parc.xerox.com>
  25.  
  26. I think Ned (who I just added to the growing distribution list on this
  27. exchange!)'s argument was that formats such as Postscript and Gif have
  28. developed or are developing ways of specifying such things IN-band, that
  29. is, in the actual data stream itself rather than in an out-of-band
  30. location such as the MIME content-type header.  Insofar as this is true,
  31. I think it makes much more sense NOT to further complicate matters by
  32. introducing a way to specify these matters out-of-band.  In other words,
  33. including information in a place like the MIME Content-type header
  34. should only be done if there's no way for including the information in
  35. part of the actual data, that is, the MIME body part.  I think that's
  36. the essential philosophy behind that choice, at any rate.  -- Nathaniel
  37.